Relearning of MAC addresses (Media Access Control Addresses) is a well known procedure in modern communication networks, and usually it takes place when the network topology changes for any reason. For example, a path to some device having a MAC address 1 has changed, but that MAC address 1 has not yet been relearned with reference to the mentioned new path (so-called “MAC move” event). To relearn the MAC address 1 in association with the new path/new port of a switch, the previously learned information (about association of the MAC address 1 with the previous specific port) should be deleted, in other words “flushed” from that specific previous port. Let us call the step of deleting as step a). The decision to flush MACs is usually taken by Central Processing Unit CPU of the switch either as a result of detecting a change in the connectivity state of the logical interface (failure of attachment circuit AC, Tunnel, pseudo wire PW, etc.) or as a result of a request/message from a user (Element Management System EMS, Common Line Interface CLI, Network Management System NMS), or other network elements (TCN, CCN) for example a MAC Withdraw message, etc.
Then comes step b) flooding packets, addressed to the MAC address 1 of interest, though all relevant interfaces (logical/physical) of the switching device, and then step c)—upon receiving a packet from the source having MAC address 1, registering this MAC address 1 in association with that port of the switch, via which the packet has arrived to the switch.
There are two common presently known practices to perform the flooding:
1. The switch may scan its internal Forwarding Data Base FDB and remove all the flushed MAC's from the FDB one by one. In systems with a lot of learned MACs (100 k+) this may take a significant time, thus affecting connectivity of the service and of the switch.
2. Alternatively, the switch may enter the “flushing/flooding” mode for the service, where the steps (a) and (b) are combined together. During the flushing/flooding mode, the relevant MAC's will be removed from the FDB (either by ageing or by specific SW/HW/FW operations). Then, the switch may enter the combined “flooding/learning” state (steps (b) and (c)=learning). This approach may be more efficient than the approach 1, however it still has disadvantages. For example, during the “flushing/flooding” the switch will flood to all MACs even if these MACs arrive from a new virtual interface, i.e., “tries to be relearned”. This will result in unnecessary flooding which in turn lengthens the process and may affect the service connectivity.
In practice today, the step (c) of real relearning is delayed till the end of the flooding. It is admitted by all the presently known techniques that the flooding and the relearning steps (b and c) cannot be effectively performed simultaneously. More accurately, if one or more MAC addresses have been relearned during the flooding operation, it is impossible to perform correct forwarding to these MAC addresses up to the end of the flooding operation.
Further it should be noted that, in real networks, not only MAC address 1 but many other MAC addresses may be associated with a specific port being currently flushed. In case that MAC address 1 “moves” to another port, other MAC addresses may need to remain registered at the discussed port; nevertheless, since usually all the information from the port is being flushed when one address is flushed, these “other” MAC addresses will be deleted. Moreover, both the MAC address 1 and these other MAC addresses must wait till the end of the flushing process including the flooding, and only then will they be learned and registered again.
Such “full flush” usually occurs when CPU of the switch retrieves the complete Forwarding Data Base (FDB) from NPU (Network Processing Unit, usually a chip associated with CPU) per each flush request. The learning/re-learning will be temporarily disabled during the flushing. As was mentioned, alternatively the CPU may precisely remove a number of relevant MAC addresses from the FDB. In any case, these operations are slow (10 s to 100 s of seconds), desynchronize FDB and affect other CPU-NPU communications (such as messages of IGMP and OAM).
A number of prior art documents try resolving problems of the MAC flush operation, for example:
U.S. Pat. No. 6,330,229B describes management of forwarding databases (FDB) in the case of link failures on bridges according to a spanning tree protocol, limits the propagation of notifications of topology change to only those parts of the network which are affected by the link failures. The technique also triggers partial flushing as opposed to complete flushing of FDB to relearn the sets of addresses associated with ports affected by the change in topology.CN101572668A describes a technique for fast removal of MAC addresses from an interface being flushed. The method comprises storing all the MAC addresses corresponding to and learnt by interfaces, which need fast deletion, searching all the MAC addresses in the MAC table with MAC addresses to be deleted, and deleting the MAC addresses fast, by the microcode of a network processor. The solution shortens the deleting time of MAC addresses and the switching time of the circuit protection.US2010027543A describes layer two MAC flushing/re-routing and proposes a solution for forwarding packets based on checking their destination address, address identifier and event identifier. The solution automatically identifies Change Topology Events and performs flooding of packets as a result.However, neither US2010027543, nor other above-mentioned documents provide any mechanism of optimized, instant flushing and/or relearning of MAC addresses.